Acoperă proiectarea sistemelor informaționale. Clasificarea metodelor de proiectare a sistemelor informatice

Proiecta sisteme informatice este un proces în mai multe etape de creare și/sau modernizare a acestora prin utilizarea unui set ordonat de metodologii și instrumente. Proiectarea (spre deosebire de modelare) presupune lucrul cu un obiect inexistent și are ca scop crearea unui sistem informațional în domeniul:

• prelucrarea obiectelor viitoarei baze de date,
• programe de scriere (inclusiv formulare de raportare și ecran) care asigură executarea interogărilor la date,
• ținând cont de funcționarea unui mediu specific (tehnologie).

Dacă identificăm etapa de proiectare a sistemelor informaționale ca o etapă separată, atunci aceasta poate fi plasată între etapele de analiză și dezvoltare. Cu toate acestea, în practică, o împărțire clară în etape este de obicei dificilă sau imposibilă, deoarece proiectarea, începând în mod oficial cu definirea scopului proiectului, continuă adesea în etapele de testare și implementare.

Scopul proiectării sistemului informațional și conceptele aferente

Managerii moderni ai organizațiilor publice și private sunt conștienți de faptul că viteza de procesare a informațiilor, care se schimbă constant și crește în volum, este o chestiune de supraviețuire a companiei pe piață și de avantaj competitiv. ÎN vedere generală Setările țintă ale proiectelor pentru crearea de sisteme informaționale sunt reduse la furnizarea de condiții care să permită recepționarea, prelucrarea și utilizarea acestor informații prin crearea unui sistem funcțional, sigur, cu suficiente:

• nivelul de adaptabilitate la condițiile în schimbare,
• debit,
• timpul de răspuns al sistemului la o solicitare,
• nivelul de securitate,
• gradul de ușurință în utilizare.

Un sistem informațional (IS) este o colecție de informații conținute într-o bază de date și tehnologii (precum și instrumente tehnice) care permit prelucrarea informațiilor. În acest caz, tehnologiile includ metode de detectare, colectare, procesare, stocare, distribuire a informațiilor și metode care permit implementarea acestor metode. Managementul informațiilor aceasta se rezumă la utilizarea acestor metode pentru a controla procesele de planificare, proiectare, operare și analiză a SI. Tehnologia de proiectare se bazează pe metodologia aleasă pentru o anumită sarcină ca un set de principii exprimate într-un singur concept definit.

Organizarea designului IP

Organizarea designului IC este de obicei împărțită în 2 tipuri:

1. Designul canonic reflectă caracteristicile tehnologice ale procesului original (individual).
2. Designul standard, care se caracterizează printr-o soluție de proiectare standard (TDS), este replicat și potrivit pentru utilizare repetată.

Designul canonic se distinge prin reflectarea tehnologiei de proiectare manuală, implementarea la nivel de performeri și utilizarea instrumentelor universale de asistență computerizată.

Designul canonic este utilizat în principal pentru circuite integrate locale și relativ mici, cu utilizarea minimă a soluțiilor standard. Adaptarea soluțiilor de proiectare are loc numai prin reprogramarea modulelor software.

Designul canonic este organizat folosind un model în cascadă ciclu de viață. Aceasta presupune împărțirea procesului în următoarele etape și etape:

1. Etapa pre-proiect. Se efectuează o analiză pre-proiect și se întocmește o specificație tehnică. Adică se formează cerințele pentru sistemul informațional, se dezvoltă conceptul acestuia, se întocmește un studiu de fezabilitate și se scriu specificații tehnice.
2. Etapa de proiectare presupune pregătirea proiectelor preliminare și tehnice, elaborarea documentației de lucru.
3. Etapa post-proiect demarează activitățile de implementare a SI, instruirea personalului și analiza rezultatelor testelor. O parte a acestei etape este menținerea PI și eliminarea deficiențelor identificate.

Etapele, dacă este necesar, pot fi mărite sau detaliate - combinați etapele succesive, eliminați-le pe cele „inutile”, începeți următoarea etapă înainte de a o finaliza pe cea anterioară.

Metoda de proiectare standard se distinge prin capacitatea de a descompune IS proiectat în componente, care includ module software, subsisteme, seturi de sarcini etc. Pentru a implementa componente, puteți utiliza soluții standard care există deja pe piață și le puteți personaliza pentru a se potrivi. nevoile unei anumite organizaţii. În acest caz, proiectarea standard necesită disponibilitatea obligatorie a documentației care descrie în detaliu TPR și procedurile de configurare.

Descompunerea poate avea mai multe niveluri, ceea ce face posibilă distingerea claselor de TPR:

• elemental – pentru o sarcină separată (element),
• subsistem - pentru subsisteme individuale,
• obiect - soluții de proiectare standard ale industriei care conțin întregul set de subsisteme.

Abilitatea de a implementa o abordare modulară este considerată un avantaj al TPR-urilor elementare. Cu toate acestea, dacă elementele diferite sunt incompatibile, procesul de combinare a acestora duce la creșterea costurilor. Subsistemul TPR, pe lângă implementarea unei abordări modulare, face posibilă realizarea unei configurații parametrice pentru obiecte la diferite niveluri de control. Problemele de consolidare apar atunci când este implicat produsul mai multor producători diferiți de software. În plus, adaptabilitatea TPR din punctul de vedere al reinginerării continue a proceselor este considerată insuficientă. TPR-urile obiect, în comparație cu clasele anterioare, au un număr mare de avantaje:

• scalabilitate, care face posibilă utilizarea configurațiilor IS pentru un număr diferit de stații de lucru,
• unitatea metodologică a componentelor,
• compatibilitatea componentelor IC,
• deschiderea arhitecturii - capacitatea de a implementa soluții de proiectare pe platforme de diferite tipuri,
• configurabilitate – capacitatea de a utiliza subsetul dorit de componente IS.

În timpul implementării proiectării standard, sunt utilizate abordări orientate spre parametri și orientate pe model.

Metodologii de bază de proiectare IC

Caracteristicile specifice ale procesului de proiectare fac posibilă distingerea metodologiilor construite pe principii diferite. Printre principalele metodologii moderne de proiectare IC se numără următoarele:

• SADT. Metodologia de modelare a muncii funcționale, care se bazează pe analiza structurală și reprezentare grafică organizarea ca sistem de funcţii. Aici distingem modele funcționale, informaționale și dinamice. Metodologia este cunoscută în prezent ca notația IDEF0 (standard). Procesul analizat este reprezentat grafic sub forma unui patrulater, unde influențele de reglementare și de control sunt reprezentate în partea de sus, obiectele de control în partea de jos, datele de intrare în stânga și datele de ieșire în dreapta.
• RAD. Metodologie de dezvoltare rapidă a aplicațiilor. RAD permite dezvoltarea rapidă a aplicațiilor prin utilizarea designului bazat pe componente. Metodologia este utilizată pentru proiecte cu un buget limitat, cerințe neclare pentru IP și termene scurte de implementare. Este folosit dacă interfața cu utilizatorul poate fi demonstrată într-un prototip, iar proiectul poate fi împărțit în elemente funcționale.
• RUP. Metodologia RUP implementează abordări iterative și incrementale. Sistemul este construit pe baza arhitecturii sistemului informațional și a planificării și management de proiect– la bază cerințe funcționale la IS. Dezvoltarea unui sistem informatic general are loc în iterații, ca un complex de proiecte individuale mici, cu propriile planuri și sarcini. Ciclul iterativ este caracterizat de un periodic feedbackși adaptarea la nucleul IS.

Există mai multe clasificări ale metodologiilor: pentru utilizarea TPR, pentru utilizarea instrumentelor de automatizare etc. De exemplu, după gradul de adaptabilitate, reconstrucții (când modulele sunt reprogramate), parametrizare (când modificarea parametrilor presupune generarea unui soluție de proiectare), restructurare (la schimbarea modelului zonei cu probleme) se disting însoțite de generarea automată a unei soluții de proiectare).

Definirea unei strategii de testare

După cum sa menționat mai devreme, pe etapa de analiză grupuri de testare sunt implicate, de exemplu, pentru a obține caracteristici comparative ale platformelor hardware destinate utilizării, sisteme de operare, DBMS, alt mediu. În plus, în această etapă, se stabilește un plan de lucru care să asigure fiabilitatea sistemului informațional și testarea acestuia. Pentru orice proiect, este recomandabil să implicați testeri în fazele incipiente de dezvoltare, în special în faza de analiză și proiectare.

Dacă o decizie de proiectare nu are succes și este descoperită prea târziu - în timpul etapei de dezvoltare sau, chiar mai rău, în timpul etapei de implementare - atunci corectarea erorii de proiectare poate fi foarte costisitoare. Cu cât echipele de testare identifică mai devreme erorile într-un sistem informatic, cu atât costul de întreținere a sistemului este mai mic. Timpul pentru testarea sistemului și corectarea erorilor detectate ar trebui furnizat nu numai în etapa de dezvoltare, ci și în etapa de proiectare. Pentru a automatiza testarea, ar trebui să utilizați sisteme de urmărire a erorilor. Acest lucru vă permite să aveți o singură stocare a erorilor, să urmăriți reapariția acestora, să controlați viteza și eficiența remedieri de erori , vezi cele mai instabile componente ale sistemului și mențin, de asemenea, comunicarea între grupul de dezvoltare și grupul de testare (notificări de modificări prin e-mail etc.). Cum mai mult proiect

, cu atât este mai puternică nevoia de urmărire a erorilor.

În etapa de proiectare, se formează un model de date. Designerii primesc rezultatele analizei ca informații inițiale. Produsul final al fazei de proiectare este:

• diagrama bazei de date (pe baza modelului ER dezvoltat la etapa de analiza);
• un set de specificații ale modulelor de sistem (sunt construite pe baza modelelor funcționale).

Dacă proiectul este mic, atunci aceiași oameni pot acționa ca analiști, designeri și dezvoltatori. Apare întrebarea: cât de relevant este transferul rezultatelor către sine? Credem că este relevant. Imaginați-vă că predați date cuiva care nu știe prea multe despre sistem. Adesea, acest lucru ajută, de exemplu, la găsirea componentelor sistemului care nu sunt descrise deloc, descrise neclar sau descrise inconsecvent.

Toate specificațiile trebuie să fie exacte. Planul de testare a sistemului este, de asemenea, finalizat în această etapă de dezvoltare. În multe proiecte, rezultatele fazei de proiectare sunt documentate într-un singur document numit specificație tehnică. De asemenea, descrie abordarea adoptată pentru rezolvarea oricăror probleme tehnice complexe.

Jurnal de design

La proiectare, este necesar să se înregistreze toate opțiunile discutate și decizii finale. Nu este un secret pentru nimeni că designerii își schimbă uneori deciziile inițiale. Acest lucru se poate întâmpla deoarece, în timp, participanții la proiect uită argumentele în favoarea decizie luată. Astfel de informații pot fi stocate în depozitul instrumentului CASE utilizat, în fișiere text, sau pur și simplu pe hârtie. Design Journal este o resursă utilă pentru noii membri ai echipelor de proiectare, precum și pentru dezvoltatori și testeri.

Un astfel de jurnal poate fi menținut atât în ​​etapa de analiză, cât și în etapa de dezvoltare și testare.

Planificarea fazei de proiectare

Planificarea atentă este importantă pentru orice proiect. Aceasta este responsabilitatea managerului de proiect și a liderului echipei de proiectare (consultările cu analiștii în acest caz vor fi obligatorii). Acest lucru vă permite să:

• Împărțiți sarcina globală în sarcini mici, independente. Astfel de sarcini sunt mai ușor de gestionat, astfel de sarcini sunt mai ușor de implementat.
• Stabiliți datele țintă (etapele de livrare), care vă vor permite să determinați cât de bine progresează proiectul, care zone sunt în urmă, care sunt subutilizate, care funcționează cu succes. Acest lucru vă permite să detectați întârzierile în termenele limită de livrare și să preveniți situațiile de urgență la timp.
• Determinați dependențele dintre sarcini, precum și succesiunea în care sarcinile sunt finalizate.
• Prognozați încărcarea personalului, angajați lucrători temporari, atrageți alte echipe de dezvoltare, atrageți consultanți (dacă este necesar).
• Obțineți o idee clară despre când poate începe faza de implementare.
• Obțineți o idee clară despre când poate începe faza pilot.

Stadiile incipiente

Revizuirea rezultatelor analizei

Acesta este procesul real de transfer de informații de la analiști la designeri. În practică, acesta este un proces iterativ. Designerii vor avea inevitabil întrebări pentru analiști și invers. Informațiile despre sistem vor fi actualizate în mod constant. Schema bazei de date se poate modifica pe măsură ce proiectați model informativ

, obținut în etapa de analiză, de exemplu, deoarece soluția de proiectare existentă este instabilă sau funcționează lent atunci când este implementată prin SGBD selectat sau din alte motive. Designerii nu pot verifica dacă analiza acoperă toate procesele de afaceri ale sistemului (adică să verifice caracterul complet), dar proiectanții pot verifica modelul de informații pentru consecvență și corectitudine. Acest lucru vă permite să urmăriți erorile în modelul de informații și să nu le repetați în modelul de date. Dacă rezultatele sunt stocate în depozitul de instrumente CASE, atunci această verificare a corectitudinii se poate face automat.

Zone critice

Adesea sunt identificate zone critice în timpul fazei de proiectare care nu au fost evidente în timpul fazei de analiză. Aceasta implică necesitatea clarificării modelului informațional. Acest lucru se datorează adesea particularităților implementării anumitor capabilități în DBMS selectat. Unele funcții care par simple în etapa de analiză pot deveni foarte complexe atunci când vine vorba de implementarea fizică. De exemplu:

• Nu este disponibil în SGBD selectat mecanism eficient scanări ale copacilor și analize dezvăluite număr mare S-au ales directoare și interfețe de prezentare sub formă de arbori, în plus clientului i-a plăcut, iar DBMS-ul cu un director mare funcționează prea încet.
• O altă neplăcere comună este integritatea referenţială incompletă. SGBD nu implementează modificări în cascadă în modelul de informații, relațiile normalizate presupun prezența ștergerilor și actualizărilor în cascadă. Implementarea unor astfel de mecanisme prin intermediul declanșatorilor s-a dovedit a fi prea lentă, iar nivelul declanșatorilor în cascadă este mai scăzut decât nivelul operațiilor în cascadă definit în modelul informațional.

Astfel de momente pot iniția nu doar o schimbare a modelului informațional, ci și o schimbare a SGBD.

Există o relație strânsă între zonele critice ale unui proiect și riscurile acestuia.

O secțiune critică de dezvoltare (de exemplu, nerespectarea termenelor pentru prima etapă de livrare a proiectului către client) poate costa întregul proiect. Motivele eșecului ar putea fi atât erorile de proiectare, cât și lipsa de personal.

Evaluarea constrângerilor

Constrângerile care au fost cunoscute de la studiul procesului de afaceri sunt estimările de costuri și termenele de implementare. Pot exista și alte restricții, de exemplu, accesul personalului la anumite informații (grupuri de analiști la informații despre procesele de afaceri din companie, restricții privind accesul la informații clasificate etc.).

Dacă proiectul este o extindere sau modernizare a unui sistem informațional existent, atunci numărul constrângerilor moștenite poate fi, de asemenea, mare. În faza de proiectare, se efectuează o verificare obligatorie a cerințelor pentru sistemul informațional în lumina limitărilor identificate. Schimbarea unei platforme, a unui sistem de operare sau a DBMS în etapa de implementare este dificilă, iar în etapa de operare de probă este aproape imposibilă (pur și simplu nu este suficient timp pentru asta, dacă nu se întâmplă un miracol). Cu cât este mai mare numărul de componente ale sistemului care au fost deja implementate, cu atât este mai dificil să faci o astfel de înlocuire. Majoritatea SGBD-urilor rulează acum pe mai multe platforme hardware și mai multe sisteme de operare, dar dacă există porțiuni din codul unui proiect care depind de sistemul de operare sau de platforma hardware, atunci schimbarea acestora poate fi foarte costisitoare. În acest articol nu vom discuta problemele portabilității codului, deoarece acestea depășesc domeniul de aplicare al acestei serii.

Dacă vreo cerință nu poate fi satisfăcută în principiu, se ia decizia de a aduce acest fapt în atenția sponsorilor de proiect (conducerea companiei).

Descoperirea că sistemul este inoperabil în timpul funcționării nu poate fi bine, mai ales dacă conducerea companiei primește informații că imposibilitatea cerințelor era cunoscută dinainte.

Definirea arhitecturii tinta

Prin alegerea unei arhitecturi ne referim atât la alegerea unei platforme, cât și la alegerea unui sistem de operare. Sistemul poate opera mai multe computere pe diferite platforme hardware și rulează diferite sisteme de operare.

• Dacă ați avut deja o mână de ajutor în automatizarea unei anumite afaceri și de mai multe ori, s-ar putea să găsiți o adevărată „menerie” de platforme și sisteme de operare. Portarea software-ului pe o platformă sau alta nu este un proces nedureros, iar gestionarea unei rețele eterogene poate deveni, de asemenea, problematică. Dacă circumstanțele sunt de așa natură încât software-ul de la stațiile de lucru ale utilizatorului final trebuie să ruleze sub mai multe sisteme de operare (OS), atunci este imperativ să evidențiezi secțiunile de cod dependente de sistemul de operare și să descriem strict interfețele de schimb ale componentelor sistemului de informații, făcându-le independente de sistemul de operare. Când scrieți cod pentru module care rulează sub mai multe sisteme de operare, ar trebui să vă concentrați pe cel care are cele mai stricte cerințe.
• Va fi o arhitectură pe 3 niveluri cu următoarele straturi: server, middleware (server de aplicații), software client.
• Baza de date va fi centralizată sau distribuită? Dacă baza de date este distribuită, atunci ce mecanisme vor fi utilizate pentru a menține consistența și relevanța datelor.
• Va fi baza de date omogenă, adică toate serverele de baze de date vor fi produse de la același producător (de exemplu, toate serverele sunt numai Oracle sau toate serverele sunt numai DB2 UDB). Dacă baza de date nu este omogenă, atunci ce software va fi folosit pentru schimbul de date între SGBD-uri de la diferiți producători (deja existente sau special dezvoltate ca parte a proiectului).
• Vor fi folosite servere de baze de date paralele (de exemplu, Oracle Parallel Server, DB2 UDB etc.) pentru a obține o performanță adecvată?

Aceste decizii sunt adesea luate înainte de începerea fazei de proiectare (în timpul fazei de analiză). În etapa de proiectare, este util să luăm în considerare din nou toate motivele pentru alegerea unei anumite arhitecturi și să efectuăm teste de performanță și fiabilitate ale secțiunilor critice ale sistemului informațional. Acest lucru vă va permite să evitați erorile de proiectare greu de eliminat. Destul de des, în etapa de proiectare, apar probleme neașteptate. probleme tehnice

, de exemplu, analiștii nu țin cont de grupul de utilizatori care au acces la sistemul informațional prin intermediul terminalelor text. Aceasta este o eroare de analiză, dar este dezvăluită doar în etapa de proiectare. Asemenea probleme trebuie rezolvate împreună cu analiștii care inițiază schimbarea modelului informațional.

Dacă mediul folosește o rețea, faza de proiectare trebuie să determine nivelurile de serviciu de rețea necesare și să proiecteze topologia rețelei. De asemenea, este necesar să se efectueze teste de rețea pentru a vedea dacă rețeaua existentă oferă un debit adecvat și dacă există capacitate de rezervă de rețea. Dacă rezultatul este negativ, atunci modificările necesare ale topologiei hardware și ale rețelei trebuie descrise clar.

Identificarea potenţialelor blocaje în sistemul informaţional Dacă clientul afirmă că performanța sistemului nu contează, luați această remarcă cu umor. Aceasta înseamnă doar că timpul de răspuns al sistemului la o solicitare nu este (sau nu pare clientului să fieîn acest moment

Performanța este importantă pentru orice sistem informațional. Un blocaj este momentul în care performanța sistemului scade. Un răspuns specific la întrebarea unde se află blocajele unui anumit sistem poate fi dat doar prin testare țintită specială. Dar acest lucru nu înseamnă că evaluarea potențialului blocajele

imposibil. O metodă bună este să graficați sarcina sistemului pe parcursul unei zile, săptămâni, luni etc. Puteți construi o diagramă care arată timpul de funcționare al anumitor procese de afaceri, precum și timpul de răspuns al sistemului necesar pentru un anumit proces de afaceri. Astfel de diagrame ajută la identificarea momentului în care sarcina va fi cea mai intensă. Numărul de utilizatori care lucrează simultan cu o anumită componentă este reflectat în diagramă folosind un coeficient de ponderare (Fig. 1).

În exemplul de mai sus, sunt vizibile în mod clar 3 vârfuri de activitate a sistemului, maximul dintre care are loc la ora 11. Tipul de diagramă utilizat este stivuit. Iar în diagrama prezentată în Fig. 2, se poate observa activitatea caselor de marcat în timpul zilei de lucru și o creștere a activității de descărcare a datelor în timpul orelor nelucrătoare. Astfel de diagrame ar trebui, de asemenea, să fie ponderate pentru a reflecta complexitatea procesului de afaceri, de ex.în acest exemplu

rapoartele vor avea cea mai mare pondere. Evaluarea scalelor este determinată de caracteristicile fiecărei afaceri specifice - undeva poate fi mare, undeva scăzută. Doar testarea poate răspunde la întrebarea cât de reale sunt potențialele blocaje. Aici se justifică utilizarea

Blocajele sistemului sunt evaluate mai precis în etapa de dezvoltare. Există deja componente de sistem implementate aici. Instrumentele de automatizare de testare (de exemplu, LoadRunner, WinRunner etc.) vă permit să urmăriți operațiunile pe care le efectuează o anumită aplicație (dar aceste instrumente nu pot urmări toate tipurile posibile de aplicații și cât de potrivite sunt pentru testarea proiectului dvs. - acesta este soluție aceeași ordine ca și alegerea mijloacelor dezvoltarea aplicatiilor), generează automat un script pentru lansarea simulatoarelor de lucru aplicații realeși construiți estimări ale blocajelor sistemului.

Produse de la terți

În faza de proiectare, se evaluează posibilitatea și eficacitatea utilizării produselor de forma a treia în dezvoltarea unui sistem informațional dat. De exemplu, există o sarcină pentru a efectua un anumit set de joburi (anumite joburi lot, etc.) conform unui program dat. Nu este întotdeauna recomandabil să includeți în proiect crearea unui utilitar de control al lansării aplicației, deoarece există o mulțime de utilități care efectuează aceste operațiuni, inclusiv cele distribuite gratuit. Există un alt motiv pentru care ar trebui cel puțin să vă familiarizați cu software-ul terților. Nu este un fapt că soluții la probleme similare cu ale tale nu se găsesc în practica mondială. Dacă implementările companiilor terțe sunt cunoscute, atunci ar trebui să vă familiarizați cu ele, cel puțin pentru a nu repeta

decizii proaste

Instrumentele CASE oferă multe beneficii. Pe de o parte a scalei va exista automatizarea muncii furnizate de CASE, iar pe de altă parte va fi sarcina urâtă de a converti rezultatele analizei în formatul acestui CAZ (dacă a fost folosit un alt instrument CASE pentru a oficializa rezultatele analizei sau nu a fost folosit nici unul). Unele instrumente CASE vă permit să treceți direct la proiectare și puteți reveni la analiză prin inginerie inversă. Din păcate, utilizarea ingineriei inverse într-un instrument CASE creează iluzia foarte dăunătoare că datele analizei sunt înregistrate, când de fapt acest lucru nu se întâmplă aproape niciodată, deoarece informațiile conținute în structura proiectată sunt diferite de rezultatele analizei. Este posibil să se obțină câteva date utile, dar este puțin probabil să se poată construi o imagine completă.

Infrastructură

Proiectarea și implementarea necesită resurse hardware și software special. În plus, este necesar un mecanism pentru a controla documentația și codul care este produs. Aceste probleme sunt cel mai bine abordate la începutul proiectării, mai degrabă decât în ​​timpul etapei de dezvoltare. Vom vorbi despre acest lucru mai jos în secțiunea Proces și design de cod. Când dezvoltați în echipe, veți avea nevoie de controale pentru consistența codului. Dacă dezvoltarea se realizează pe diferite platforme (platformă hardware și sistem de operare), atunci buna decizie poate fi PVCS. Pentru platformele Windows 98, NT, 2000, soluția oferită de Microsoft - MS Source Save - poate fi acceptabilă. În plus, multe instrumente de dezvoltare oferă și capabilități de control al codului sursă.

Construirea unui model de date

Munca designerilor de baze de date depinde în mare măsură de calitatea modelului de informații. Modelul informațional nu trebuie să conțină constructe de neînțeles care nu pot fi implementate în cadrul SGBD selectat. Trebuie remarcat faptul că modelul informațional este creat astfel încât un model de date să poată fi construit pe baza lui, adică trebuie să țină cont de caracteristicile de implementare ale SGBD selectat. Dacă anumite caracteristici ale SGBD nu vă permit să reflectați în modelul de date ceea ce descrie modelul de informații, atunci este necesar să schimbați modelul de informații, deoarece producătorul SGBD este puțin probabil să schimbe prompt SGB-ul în sine de dragul specificului dvs. proiect (deși astfel de cazuri, deși izolate, au avut loc).

Construirea modelelor de date logice și fizice este o parte fundamentală a proiectării bazei de date. Modelul informațional obținut în timpul procesului de analiză este mai întâi convertit într-un model de date logic și apoi într-un model de date fizic. După aceasta, este creată o bază de date de probă pentru dezvoltatorii de sisteme informatice. Dezvoltatorii de cod încep să lucreze cu el. În mod ideal, modelul de date ar trebui să fie stabil până la începerea dezvoltării. Proiectarea bazei de date nu poate fi divorțată de proiectarea modulelor și a aplicației, deoarece regulile de afaceri pot crea obiecte în baza de date, cum ar fi constrângerile de pe partea serverului, precum și procedurile stocate și declanșatoarele - caz în care se spune adesea că o parte a logicii de afaceri este transferată către baza de date. Proiectarea unui model de date pentru fiecare SGBD conține propriile sale caracteristici, decizii de proiectare care dau rezultate bune pentru un SGBD, dar pot fi complet inacceptabile pentru altul. Mai jos listăm sarcinile care sunt comune pentru proiectarea modelelor de date:

• identificarea constructelor irealizabile sau neobișnuite în modelul ER și definițiile entităților;
• rezoluția tuturor arcurilor, subtipurilor și supertipurilor;
• studiul cheilor străine posibile, primare, descrierea integrității referențiale (în funcție de implementare, declarativ sau folosind declanșatoare);
• proiectarea și implementarea denormalizării bazei de date pentru îmbunătățirea performanței;
• determinarea unei părți a logicii de business care ar trebui implementată în baza de date (pachete, proceduri stocate);
• implementarea restricțiilor (constrângeri și declanșatoare) care reflectă toate regulile de afaceri definite la nivel central, generarea de restricții și declanșatoare;
• definirea unui set de reguli de afaceri care nu pot fi specificate ca constrângeri în baza de date;
• determinarea indicilor necesari, clusterelor (dacă sunt implementate în SGBD), determinarea fragmentării orizontale a tabelelor (dacă este implementată în SGBD);
• estimarea dimensiunilor tuturor tabelelor, indicilor, clusterelor;
• determinarea dimensiunii spațiilor de masă și a caracteristicilor plasării acestora pe mediile de stocare, determinarea specificațiilor mediilor de stocare pentru un sistem industrial (de exemplu, tipul de matrice raid, numărul acestora, ce spații de masă sunt amplasate pe ele), determinarea dimensiunea spațiilor de tabelă de sistem necesare (de exemplu, directorul de sistem, jurnalul de tranzacții, spațiul de tabelă temporar etc.);
• identificarea utilizatorilor bazei de date, nivelurile de acces ale acestora, dezvoltarea și implementarea regulilor de securitate a accesului, auditarea (dacă este necesar), crearea de privilegii pachetate (în funcție de implementarea SGBD, acestea sunt roluri sau grupuri), sinonime;
• dezvoltarea topologiei bazei de date în cazul unei baze de date distribuite, determinarea mecanismelor de accesare a datelor de la distanță.

Vom intra în mai multe detalii despre fiecare dintre punctele enumerate în partea „Schema bazei de date”.

Design de proces și cod

În paralel cu proiectarea schemei bazei de date, proiectarea procesului este necesară pentru a obține specificațiile tuturor modulelor. Dacă o parte din logica de afaceri este stocată în baza de date (constrângeri, declanșatoare, proceduri stocate), atunci ambele procese de proiectare sunt strâns legate. Scopul principal al proiectării este de a mapa funcțiile obținute în etapa de analiză în modulele sistemului informațional. Definițiile modulelor sunt dezvăluite în specificațiile tehnice ale programelor.

Este posibil ca unele funcții atomice obținute în timpul fazei de analiză să nu fie mapate deloc în niciun modul, ci să fie convertite în proceduri manuale sau principii de funcționare.

Maparea funcțiilor la module

La etapa de analiză, a fost deja elaborată o listă de funcții care vor fi implementate.

În etapa de proiectare, această listă este analizată și ajustată din nou.

• O corespondență clară între o funcție și un modul este cu greu posibilă. Cert este că în etapa de analiză, funcțiile sunt organizate pe categorii de afaceri, iar în etapa de proiectare vor trebui reorganizate pentru a simplifica dezvoltarea. Proiectanții pot decide să combine mai multe funcții care au proprietăți comune sau să izoleze o proprietate comună (sau un set al acestora) într-un modul separat sau să împartă o funcție complexă în mai multe module. Aceste probleme sunt discutate mai detaliat în secțiunea Specificații funcție.
• Interfețele programului

Adesea, datele din formularele de ecran completate automat sunt grupate (situate una lângă alta), iar navigarea prin câmpurile completate de utilizator este organizată așa cum ar face utilizatorul atunci când lucrează cu un document de hârtie real. Astfel de interfețe sunt mai ușor de perceput de către utilizator și învață software-ul nou mult mai rapid.

Integrarea și moștenirea mecanismelor de schimb de date

Un sistem informatic este rareori dezvoltat de la zero. Mai des, designerii se confruntă cu sarcina de a moșteni date de la sisteme vechi care îndeplinesc deja unele sarcini de automatizare a afacerii. Astfel de sisteme pot fi integrate inițial în sistem nouși să fie înlocuite treptat cu module noi, mai moderne.

Această abordare poate fi impusă de conducerea companiei pentru a accelera introducerea unui nou sistem informatic. Ar trebui luate în considerare toate avantajele și dezavantajele unei astfel de integrări treptate (de regulă, există mai multe dezavantaje). În orice caz, va trebui făcută o singură operațiune: transferați datele valoroase stocate în vechiul sistem de informații către unul nou, adică proiectați mecanisme de conversie a datelor. Este posibil să trebuiască să convertiți datele nu numai din sistemul vechi în cel nou, ci și invers (complet sau parțial), deoarece există un posibil scenariu în care sistemele de informații vechi și noi vor funcționa în paralel - cel puțin în perioada de funcționare de probă a noului sistem.

Pe lângă problemele de moștenire a datelor în sine de la vechile sisteme informatice, este posibil să trebuiască să rezolvați și problemele de interacțiune a software-ului dumneavoastră cu produse ale unor terțe companii. În acest caz, ar trebui să studiați interfețele de schimb de date ale software-ului de la alți dezvoltatori și să asigurați nivelul adecvat de suport pentru aceste interfețe în sistemul informațional dezvoltat.

Definirea specificațiilor modulului

• Aceasta este o parte esențială a designului funcțional. Următoarele sarcini sunt rezolvate aici:
• transformarea definițiilor de analiză funcțională în module implementabile;
• specificații care exprimă funcționalitatea fiecărui modul în categorii fizice;
• determinarea instrumentelor de dezvoltare pentru fiecare modul (sau grupuri selectate de module), dacă într-un proiect sunt utilizate mai multe instrumente de dezvoltare;

Specificațiile modulului variază în detaliu și conținut, chiar și în cadrul aceluiași proiect. Ele determină cât timp este necesar pentru a genera un anumit modul, cât timp este necesar pentru a testa un anumit modul, precum și pentru a testa un set de module generate. În plus, ar trebui dezvoltate metrici speciale - șabloane care vă permit să estimați cât timp va dura crearea codului sursă al modulului. Pentru a accelera procesul de dezvoltare, ar trebui să luați în considerare utilizarea generatoarelor de cod sursă - acest lucru este recomandabil dacă trebuie să dezvoltați un număr mare de module simple, iar timpul de dezvoltare este limitat. Șabloanele de cod ar trebui folosite pentru a rezolva operațiuni de rutină. Aceste probleme sunt discutate mai detaliat în secțiunea despre specificațiile funcției, pe care o veți găsi într-un articol viitor din această serie.

ComputerPress 11"2001

Proiectare sisteme informatice

Dezvoltarea unui sistem de informații corporative, de regulă, se realizează pentru o întreprindere foarte specifică. Caracteristicile obiectului de activitate al întreprinderii vor influența cu siguranță structura sistemului informațional. Dar, în același timp, structurile diferitelor întreprinderi sunt în general similare între ele. Fiecare organizație, indiferent de tipul său de activitate, este formată dintr-un număr de divizii care desfășoară direct unul sau altul tip de activitate a companiei. Și această situație este valabilă pentru aproape toate organizațiile, indiferent de tipul de activitate în care se angajează.

Astfel, orice organizație poate fi considerată ca un ansamblu de elemente (diviziuni) care interacționează, fiecare dintre ele putând avea o structură proprie, destul de complexă. Relațiile dintre departamente sunt și ele destul de complexe. ÎN caz general pot fi distinse trei tipuri de conexiuni între departamentele întreprinderii:

 conexiuni funcţionale - fiecare departament realizează anumite tipuri de muncă în cadrul unui singur proces de afaceri;

 comunicaţii informaţionale - departamentele fac schimb de informaţii (documente, faxuri, comenzi scrise şi orale etc.);

 comunicații externe - unele departamente interacționează cu sisteme externe, iar interacțiunea acestora poate fi, de asemenea, atât informațională, cât și funcțională.

Structura comună a diferitelor întreprinderi ne permite să formulăm câteva principii comune pentru construirea sistemelor informaționale corporative.

În general procesul de dezvoltare a sistemului informatic poate fi privit din două puncte de vedere:

 în ceea ce privește principalele fluxuri de lucru: interpreți, acțiuni, succesiune de acțiuni etc.;

 după timp, sau pe etape ale ciclului de viață al sistemului în curs de dezvoltare. În acest caz, avem în vedere organizarea dinamică a procesului de dezvoltare, descrisă în termeni de cicluri, etape, iterații și etape.

Un sistem informatic al întreprinderii este dezvoltat ca proiect. Multe caracteristici ale managementului de proiect și ale fazei de dezvoltare a proiectului (fazele ciclului de viață) sunt comune și nu depind doar de domeniul subiectului, dar și de natura proiectului (nu contează dacă este un proiect de inginerie sau unul economic). Prin urmare, este logic să luăm în considerare mai întâi o serie de probleme generale de management de proiect.

Un proiect este o schimbare limitată în timp, intenționată a unui sistem separat, cu obiective inițial clar definite, a căror realizare determină finalizarea proiectului, precum și cu cerințele stabilite pentru calendar, rezultate, risc, cadru pentru cheltuirea fondurilor și resurselor. , și pentru structura organizatorică.

De obicei, pentru un concept complex (cum ar fi, în special, conceptul de proiect) este dificil să se ofere o formulare fără ambiguitate care să acopere în totalitate toate trăsăturile conceptului introdus. Prin urmare, definiția dată nu pretinde a fi unică și completă.

Se pot distinge următoarele principalele caracteristici distinctive ale proiectului ca obiect de control:

 variabilitate - transfer intentionat al unui sistem de la unul existent la unele

starea dorită, descrisă din punct de vedere al obiectivelor proiectului;

 obiectiv final limitat;

 durată limitată;

 limitări bugetare;

 resursele limitate necesare;

 noutate pentru întreprinderea pentru care se implementează proiectul;

 complexitate - prezența unui număr mare de factori care influențează direct sau indirect progresul și rezultatele proiectului;

 suport juridic și organizatoric - crearea unei structuri organizatorice specifice pe durata proiectului.

Eficiența muncii se realizează prin managementul procesului de implementare a proiectului, care asigură alocarea resurselor, coordonarea succesiunii lucrărilor efectuate și compensarea influențelor perturbatoare interne și externe.

Din punctul de vedere al teoriei sistemelor de control, un proiect ca obiect de control trebuie să fie observabil și controlabil, adică sunt identificate anumite caracteristici prin care evoluția proiectului poate fi monitorizată constant (proprietatea observabilității). În plus, sunt necesare mecanisme pentru influențarea în timp util asupra progresului proiectului (proprietatea controlabilității).

Proprietatea de controlabilitate este deosebit de importantă în condiții de incertitudine și variabilitate a domeniului subiectului, care însoțesc adesea proiectele de dezvoltare a sistemelor informaționale.

Fiecare proiect, indiferent de complexitatea și cantitatea de muncă necesară pentru implementarea sa, trece prin anumite stări în dezvoltarea sa: de la starea când „proiectul încă nu există” până la starea când „proiectul nu mai există”. Setul de etape de dezvoltare de la apariția unei idei până la finalizarea completă a unui proiect este de obicei împărțit în faze (etape, etape).

Există unele diferențe în determinarea numărului de faze și a conținutului acestora, deoarece aceste caracteristici depind în mare măsură de condițiile proiectului specific și de experiența principalilor participanți. Cu toate acestea, logica și conținutul de bază al procesului de dezvoltare a sistemului informațional sunt comune în aproape toate cazurile.

Se pot distinge următoarele faze ale dezvoltării sistemului informațional:

 formarea conceptului;

 elaborarea specificaţiilor tehnice;

 proiectare;

 fabricaţie;

 punerea în funcţiune a sistemului.

Să ne uităm la fiecare dintre ele mai detaliat.

Faza a doua și parțial a treia sunt de obicei numite faze de proiectare a sistemului, iar ultimele două (uneori faza de proiectare este inclusă și aici) sunt faze de implementare.

Faza conceptuală

 formarea ideilor, stabilirea scopurilor;

formarea unei echipe cheie de proiect;

 studierea motivației și cerințelor clientului și a altor participanți;

 colectarea datelor iniţiale şi analiza stării existente;

 identificarea cerinţelor şi limitărilor de bază, a resurselor materiale, financiare şi de muncă necesare;

 evaluarea comparativă a alternativelor;

 prezentarea propunerilor, examinarea şi aprobarea acestora.

Elaborarea unei propuneri tehnice

 dezvoltarea conţinutului principal al proiectului, structura de bază a proiectului;

 elaborarea şi aprobarea specificaţiilor tehnice;

 planificarea, descompunerea modelului structural de bază al proiectului;

 intocmirea devizelor si bugetului proiectului, determinarea necesarului de resurse;

 elaborarea planurilor calendaristice și a programelor de lucru extinse;

 semnarea unui contract cu clientul;

 punerea în funcţiune a mijloacelor de comunicare între participanţii la proiect şi monitorizarea evoluţiei lucrărilor.

Proiecta

În această fază, sunt determinate subsistemele și relațiile lor și sunt selectate cele mai eficiente modalități de implementare a proiectului și de utilizare a resurselor. Lucrul tipic al acestei faze:

 îndeplinirea de bază munca de proiectare;

 dezvoltarea privatului sarcini tehnice;

 implementarea designului conceptual;

 întocmirea specificaţiilor tehnice şi a instrucţiunilor;

 prezentarea dezvoltării, examinării și aprobării proiectării.

Dezvoltare

În această fază se realizează coordonarea și controlul operațional al lucrărilor de proiect, se fabrică, se integrează și se testează subsistemele. Conținut principal:

 executarea lucrărilor de dezvoltare software;

 pregătirea pentru implementarea sistemului;

 controlul şi reglementarea principalilor indicatori ai proiectului.

Punerea în funcțiune a sistemului

În această fază se efectuează teste, test de funcționare a sistemului în condiții reale,

Sunt în derulare negocieri cu privire la rezultatele proiectului și la posibile noi contracte. Principalele tipuri de munca:

 teste cuprinzătoare;

Conceptul de ciclu de viață este unul dintre conceptele de bază ale metodologiei de proiectare a sistemelor informaționale. Ciclul de viață al unui sistem informațional este un proces continuu care începe din momentul în care se ia decizia de a crea un sistem informațional și se termină atunci când acesta este scos complet din serviciu.

Există un standard internațional care reglementează ciclul de viață al sistemelor informatice - ISO/IEC 12207.

ISO - Organizația Internațională de Standardizare (organizație internațională de standardizare). IEC - International Electrotechnical Commission (International Commission on Electrical Engineering).

Standardul ISO/IEC 12207 definește o structură a ciclului de viață care conține procesele, activitățile și sarcinile care trebuie efectuate în timpul creării unui sistem informațional.

Conform acestui standard, structura ciclului de viață se bazează pe trei grupuri de procese:

 principalele procese ale ciclului de viață (cumpărare, furnizare, dezvoltare, operare, suport);

 procese auxiliare care asigură executarea principalelor procese (documentare, managementul configurației, asigurarea calității, verificare, certificare, evaluare, audit, rezolvare de probleme);

 procese organizatorice (managementul de proiect, crearea infrastructurii proiectului, definirea, evaluarea și îmbunătățirea ciclului de viață în sine, instruire).

Metodologia de creare a sistemelor informatice este de a organiza procesul de construire a unui sistem informatic și de a asigura managementul acestui proces pentru a se asigura că sunt îndeplinite atât cerințele pentru sistemul în sine, cât și caracteristicile procesului de dezvoltare.

Sarcinile principale, a cărui soluție ar trebui să ofere metodologie de creare a sistemelor informatice corporative(folosind un set adecvat de instrumente) sunt următoarele:

 asigurarea creării de sisteme informatice care să corespundă scopurilor și obiectivelor întreprinderii și să îndeplinească cerințele de automatizare a proceselor de afaceri;

 garanția creării unui sistem cu parametri specificați într-un timp specificat în cadrul unui buget prestabilit;

 ușurința întreținerii, modificării și extinderii sistemului pentru a asigura conformitatea acestuia cu condițiile de funcționare în schimbare ale întreprinderii;

 asigurarea creării de sisteme informaționale corporative care să îndeplinească cerințele de deschidere, portabilitate și scalabilitate;

 posibilitatea utilizării în sistemul creat de instrumente de tehnologie a informaţiei dezvoltate şi utilizate anterior (software, baze de date, echipamente informatice, telecomunicaţii).

Metodologiile, tehnologiile și instrumentele de proiectare (instrumentele CASE) formează baza oricărui proiect de sistem informațional. Metodologia este implementată prin tehnologii specifice și standarde suport, metode și instrumente care asigură implementarea proceselor ciclului de viață al sistemelor informaționale.

Tehnologia de proiectare poate fi prezentat ca o combinație de trei componente:

 o secvenţă dată de operaţii de proiectare tehnologică;

 criteriile și regulile utilizate pentru evaluarea rezultatelor operațiunilor tehnologice;

 mijloace grafice și textuale (notații) utilizate pentru a descrie sistemul proiectat.

Fiecare operațiune tehnologică trebuie asigurată următoarele resurse materiale și informaționale:

 date obţinute dintr-o operaţiune anterioară (sau date iniţiale), prezentate într-o formă standard;

 materiale metodologice, instrucțiuni, reglementări și standarde;

 software și hardware;

 interpreți.

Rezultatele operațiunii trebuie prezentate într-o formă standard, asigurându-se percepția lor adecvată la efectuarea următoarei operațiuni tehnologice (în care vor fi folosite ca date de intrare).

Se poate formula următoarea serie cerințe generale, care trebuie să satisfacă tehnologie de proiectare, dezvoltare și întreținere a sistemelor informaționale:

 sprijinirea întregului ciclu de viață al sistemului informațional;

 asigura realizarea garantată a obiectivelor de dezvoltare a sistemului cu o calitate dată și într-un timp specificat;

 să ofere posibilitatea împărţirii proiectelor mari într-un număr de subsisteme - descompunerea proiectului în părţi componente, dezvoltate de grupuri de executanţi de un număr limitat, cu integrarea ulterioară a părţilor componente;

 tehnologia ar trebui să ofere capacitatea de a efectua lucrări de proiectare a subsistemelor individuale în grupuri mici (3-7 persoane). Acest lucru se datorează principiilor managementului echipei și creșterii productivității prin minimizarea numărului de conexiuni externe;

 asigura timpul minim pentru obtinerea unui sistem de lucru;

Descompunerea proiectului vă permite să creșteți eficiența muncii. Subsistemele în care este împărțit proiectul trebuie să fie slab conectate în ceea ce privește datele și funcțiile. Fiecare subsistem este dezvoltat de un grup separat de dezvoltatori. În același timp, este necesar să se asigure coordonarea lucrărilor și să se elimine dublarea rezultatelor obținute de fiecare grup de proiect. Ceea ce se înțelege aici nu este implementarea sistemului informațional în ansamblu, ci dezvoltarea subsistemelor sale individuale. De regulă, chiar și în prezența unui proiect complet finalizat, implementarea sistemului dezvoltat se realizează secvenţial, în subsisteme separate. Implementarea întregului sistem într-un timp scurt poate necesita implicarea unui număr mare de dezvoltatori, iar efectul poate fi mai mic decât la implementarea subsistemelor individuale într-un timp mai scurt de către un număr mai mic de dezvoltatori.

 să ofere capacitatea de a gestiona configurația proiectului, de a menține versiunile proiectului și ale componentelor acestuia și abilitatea de a lansa automat documentatia proiectuluiși sincronizarea versiunilor sale cu versiunile de proiect;

 asigurarea independenţei soluţiilor de proiectare implementate faţă de mijloacele de implementare a sistemului - sistem de management al bazei de date, sistem de operare, limbaj şi sistem de programare.

Crearea, întreținerea și dezvoltarea sistemelor informatice complexe moderne se bazează pe metodologia de construire a unor astfel de sisteme precum cele deschise. Sistemele informaționale deschise sunt create în procesul de informatizare a tuturor sferelor principale ale societății moderne: organisme guvernamentale, sfere financiare și de credit, servicii de informare pentru activitățile de afaceri, sfera producției, știință, educație. Dezvoltarea și utilizarea sistemelor informaționale deschise sunt indisolubil legate de aplicarea standardelor bazate pe metodologia de standardizare funcțională a tehnologiilor informaționale.

Conceptul de profil al unui sistem informatic

La crearea și dezvoltarea sistemelor informaționale complexe, distribuite, replicate, este necesară formarea și aplicarea flexibilă a unor seturi armonizate de standarde de bază și documente de reglementare de diferite niveluri, evidențiind în acestea cerințele și recomandările necesare implementării funcțiilor specificate ale sistemului. . Pentru unificare și reglementare, astfel de seturi de standarde de bază trebuie adaptate și specificate în legătură cu anumite clase de proiecte, funcții, procese și componente ale sistemului. În acest sens, a fost evidențiat și format conceptul de profil al sistemului informațional ca principal instrument de standardizare funcțională.

Profil este un set de mai multe (sau un subset al unuia) standarde de bază cu subseturi clar definite și armonizate de capabilități obligatorii și opționale, concepute pentru a implementa o anumită funcție sau grup de funcții.

Profilul se formează pe baza caracteristicilor funcționale ale obiectului de standardizare. Profilul identifică și stabilește capabilitățile acceptabile și valorile parametrilor fiecărui standard de bază și/sau document de reglementare inclus în profil.

Profilul nu trebuie să contravină standardelor de bază și documentelor de reglementare utilizate în el. El trebuie să aplice selectat din opțiuni alternative caracteristici opționale și valori ale parametrilor în limite acceptabile.

Pe baza unui set de standarde de bază, pot fi formate și aprobate diferite profiluri pentru diferite proiecte de sisteme informatice. Limitările documentelor de profil de bază și consistența acestora, realizate de dezvoltatorii de profil, trebuie să asigure calitatea, compatibilitatea și interacțiunea corectă a componentelor individuale ale sistemului corespunzătoare profilului în domeniul dat de aplicare a acestuia.

Standardele și profilurile de bază, în funcție de aria de aplicare a sistemelor informaționale orientate către probleme, pot fi utilizate ca documente directe, de îndrumare sau de consiliere, precum și ca cadrul de reglementare, necesar la alegerea sau dezvoltarea instrumentelor de automatizare pentru etapele tehnologice sau procesele de creare, întreținere și dezvoltare a sistemelor informaționale.

De obicei luate în considerare două grupuri de profiluri:

 reglementarea arhitecturii şi structurii sistemului informaţional;

 reglementarea proceselor de proiectare, dezvoltare, aplicare, întreţinere şi dezvoltare a sistemului.

În funcție de domeniul de aplicare, profilurile pot avea diferite categorii și, în consecință, diferite stări de aprobare:

 profile ale unui sistem informatic specific, definind soluţii standardizate de proiectare în cadrul unui proiect dat;

 profiluri ale sistemelor informatice destinate să rezolve o anumită clasă de probleme aplicate.

Profilurile sistemelor informatice unifică și reglementează doar o parte din cerințele, caracteristicile, indicatorii de calitate ai obiectelor și proceselor, identificate și formalizate pe baza standardelor și documentelor de reglementare. O altă parte a funcționalului și caracteristici tehnice sistemele sunt determinate de clienți și dezvoltatori în mod creativ, fără a ține cont de prevederile documentelor de reglementare.

Principiile formării unui profil de sistem informațional

Utilizarea profilurilor sistemelor informatice are scopul de a rezolva următoarele probleme:

 reducerea intensităţii forţei de muncă a proiectelor;

 îmbunătățirea calității componentelor sistemului informațional;

 asigurarea extensibilității și scalabilității sistemelor dezvoltate;

 asigurarea posibilităţii de integrare funcţională în sistemul informaţional a sarcinilor care anterior au fost rezolvate separat;

 asigurarea portabilităţii software-ului aplicaţiei.

În funcție de care dintre aceste sarcini are cea mai mare prioritate, standardele și documentele sunt selectate pentru a forma un profil.

Relevanța utilizării profilurilor sistemului informațional se datorează modernității starea standardizării tehnologiei informației, care se caracterizează prin următoarele caracteristici:

 există multe standarde internaționale și naționale care nu sunt

satisface pe deplin și neuniform nevoia de standardizare a obiectelor și proceselor pentru crearea și utilizarea sistemelor informaționale complexe;

 perioade lungi de dezvoltare, coordonare și aprobare a standardelor internaționale și naționale duc la conservatorismul acestora și la decalaj cronic în urma tehnologiilor informaționale moderne;

 standardele funcționale susțin și reglementează doar cele mai simple obiecte și procese de rutină, de masă: telecomunicații, programare, documentare a programelor și a datelor. Cele mai complexe și creative procese de creare și dezvoltare a sistemelor de informații mari distribuite sunt analiza sistemuluiși proiectarea, integrarea componentelor și sistemelor, testarea și certificarea - aproape că nu sunt susținute de cerințele și recomandările standardelor din cauza dificultății formalizării și unificării lor;

 îmbunătățirea și armonizarea documentelor normative și metodologice în unele cazuri face posibilă crearea standardelor naționale și internaționale pe baza acestora.

Abordările pentru formarea profilurilor sistemului informațional pot fi diferite. În standardizarea funcțională internațională a tehnologiilor informaționale, a fost adoptat un concept destul de rigid de profil. Se crede că doar standardele internaționale și naționale aprobate pot sta la baza acestuia. Utilizarea standardelor de facto și a reglementărilor companiei nu este permisă. Cu această abordare, este dificil de unificat, reglat și parametrizat multe funcții și caracteristici specifice ale obiectelor complexe din arhitectura și structura sistemelor informaționale moderne. O altă abordare a dezvoltării și aplicării profilurilor sistemelor informaționale este utilizarea unui set de standarde internaționale și naționale de bază adaptate și parametrizate și specificații deschise care îndeplinesc standardele și recomandările de facto ale consorțiilor internaționale.

Model de referință al mediului sisteme deschise(OSE/RM) definește împărțirea oricărui sistem informațional în două componente: aplicații (programe de aplicație și sisteme software) și mediul în care operează aceste aplicații.

Interfețele standardizate sunt definite între aplicații și mediu - Application Program Interface (API), care sunt o parte necesară a profilurilor oricărui sistem deschis.

În plus, profilurile pot defini interfețe unificate pentru interacțiunea părților funcționale între ele și interfețe pentru interacțiunea între componentele mediului de sistem. Specificațiile funcțiilor îndeplinite și interfețele de interacțiune pot fi prezentate sub formă de profile ale componentelor sistemului.

Astfel, profiluri ale sistemului informatic cu structură ierarhică poate include:

 descrieri standardizate ale funcţiilor îndeplinite de sistem;

 funcţiile de interacţiune a sistemului cu mediul său extern;

 interfeţe standardizate între aplicaţii şi mediul sistemului informaţional;

 profile ale componentelor funcţionale individuale incluse în sistem. Pentru a utiliza eficient un anumit profil, trebuie să:

 evidenţiază domenii de funcţionare orientate către probleme unite printr-o conexiune logică, unde pot fi aplicate standarde comune unei organizaţii sau unui grup de organizaţii;

 identifică standardele și reglementările, cazurile de utilizare ale acestora și parametrii care trebuie incluși în profil;

 documentează zonele unui profil specific în care este necesară crearea de noi standarde sau documente normative și identifică caracteristicile care pot fi importante pentru dezvoltarea standardelor și documentelor normative lipsă ale acestui profil;

 să formalizeze profilul în conformitate cu categoria sa, inclusiv standarde, diverse versiuni ale documentelor de reglementare și parametri suplimentari care au legătură directă cu profilul;

Atunci când utilizați profile, este important să vă asigurați că acestea sunt utilizate corect prin testare, testare și certificare. Acest lucru necesită crearea unei tehnologii de monitorizare și testare în timpul aplicării profilului. Această tehnologie trebuie să fie susținută de un set de metode, instrumente, compoziție și conținut al documentelor întocmite la fiecare etapă a proiectului.

Utilizarea profilurilor promovează unificarea în elaborarea testelor care verifică calitatea și interacțiunea componentelor sistemului informațional proiectat. Profilurile ar trebui definite astfel încât testarea implementării lor să poată fi realizată cât mai complet posibil folosind o metodologie standardizată. În acest caz, este posibil să se utilizeze metode dezvoltate anterior, deoarece standardele și profilurile internaționale stau la baza creării de teste de certificare general recunoscute.

Structura profilurilor sistemului informatic

Dezvoltarea și aplicarea profilurilor reprezintă o parte organică a proceselor de proiectare, dezvoltare și întreținere a sistemelor informaționale. Profilurile caracterizează fiecare sistem informațional specific în toate etapele ciclului său de viață, specificând un set agreat de standarde de bază la care trebuie să se conformeze sistemul și componentele sale. Standardele care sunt importante din punctul de vedere al clientului ar trebui să fie specificate în termenii de referință pentru proiectarea sistemului și să constituie profilul său principal. Ceea ce nu este specificat în specificațiile tehnice rămâne inițial la latitudinea dezvoltatorului de sistem, care, ghidat de cerințele specificațiilor tehnice, poate completa și dezvolta profile de sistem și, ulterior, le poate coordona cu clientul. Astfel, profilul unui anumit sistem nu este static, se dezvoltă și este specificat în procesul de proiectare a unui sistem informațional și este formalizat ca parte a documentației de proiectare a sistemului.

Profilul unui sistem specific include specificațiile componentelor dezvoltate ca parte a acestui proiect și specificațiile software-ului și hardware-ului standard utilizat, dacă aceste instrumente nu sunt specificate de standardele corespunzătoare. După finalizarea proiectării și testării sistemului, în timpul căreia se verifică conformitatea acestuia cu profilul, profilul este utilizat ca instrument principal de susținere a sistemului în timpul funcționării, modernizării și dezvoltării.

Proiectarea sistemelor informaționale (IS) este o activitate complexă în mai multe etape, fără organizarea științifică a cărei creare și utilizare a SI complex modern este de neconceput, inclusiv în educație, antreprenoriat, management și alte domenii ale societății. Odată cu obținerea cunoștințelor teoretice necesare pentru aceasta, designerul IS trebuie să dobândească abilități practice stabile în acest tip de activitate.

Principala caracteristică a designului este lucrul cu un obiect care nu există încă. Aceasta este diferența dintre design și modelare, unde un obiect nu poate decât să existe.

Designul IC acoperă trei domenii principale:

Proiectarea obiectelor de date care vor fi implementate în baza de date;

Proiectarea de programe, formulare de ecran, rapoarte care vor asigura executarea interogarilor de date;

Luând în considerare mediul sau tehnologia specifică, și anume: topologia rețelei, configurația hardware, arhitectura utilizată (fișier-server sau client-server), procesare paralelă, prelucrare distribuită a datelor etc.

Proiectarea sistemelor informatice începe întotdeauna cu definirea scopului proiectului. În termeni generali, scopul proiectului poate fi definit ca rezolvarea unui număr de sarcini interdependente, inclusiv asigurarea în momentul lansării sistemului și pe toată perioada de funcționare a acestuia:

Funcționalitatea necesară a sistemului și nivelul de adaptabilitate al acestuia la condițiile de funcționare în schimbare;

Debitul de sistem necesar;

Timpul de răspuns necesar al sistemului la o solicitare;

Funcționarea fără defecțiuni a sistemului;

Nivelul de securitate necesar;

Ușurință în operare și suport de sistem.

Tehnologia de proiectare

Tehnologia de proiectare AIS este un set de metode și mijloace pentru proiectarea AIS, precum și metode și mijloace de organizare a proiectării (gestionarea procesului de creare și modernizare a unui proiect AIS). Tehnologia de proiectare se bazează pe procesul tehnologic (TP), care determină acțiunile, succesiunea acestora, componența executanților, mijloacele și resursele necesare pentru realizarea acestor acțiuni.

TP of AIS design este un set de lanțuri de acțiuni secvenţial-paralele, conectate și subordonate, fiecare dintre acestea putând avea propriul subiect. Acțiunile care se realizează la proiectarea unui AIS pot fi definite ca operații tehnologice indivizibile sau ca subprocese ale operațiilor tehnologice.

Toate acțiunile pot fi proiectate efectiv, care formează sau modifică rezultatele proiectării, și evaluative, care sunt dezvoltate conform criteriilor stabilite pentru evaluarea rezultatelor proiectării.

Astfel, tehnologia de proiectare este determinată de o succesiune reglementată de operațiuni tehnologice efectuate în procesul de creare a unui proiect bazat pe una sau alta metodă.

Subiectul tehnologiei de proiectare selectată ar trebui să fie o reflectare a proceselor de proiectare interconectate în toate etapele ciclului de viață AIS.

Principalele cerințe pentru tehnologia de proiectare selectată sunt următoarele:

Proiectul creat folosind această tehnologie trebuie să corespundă cerințelor clientului;

Tehnologia ar trebui să reflecte cât mai mult posibil toate etapele ciclului de viață al proiectului;

Tehnologia trebuie să asigure costuri minime de forță de muncă și costuri pentru proiectare și suport pentru proiect;

Tehnologia ar trebui să ajute la creșterea productivității designerilor;

Tehnologia trebuie să asigure fiabilitatea proiectării și funcționării proiectului;

Tehnologia ar trebui să faciliteze întreținerea ușoară a documentației proiectului.

Tehnologia de proiectare AIS implementează o metodologie de proiectare specifică. La rândul său, metodologia de proiectare presupune prezența unui anumit concept, principii de proiectare și este implementată printr-un set de metode și instrumente.

Metodele de proiectare AIS pot fi clasificate în funcție de gradul de utilizare a instrumentelor de automatizare, soluții standard de proiectare și adaptabilitate la schimbările așteptate.

După gradul de automatizare există:

Proiectare manuală;

Proiectare asistată de calculator;

Pe baza gradului de utilizare a soluțiilor standard de proiectare, acestea se disting:

Design original;

Design standard;

Următoarele metode diferă în ceea ce privește gradul de adaptabilitate al soluțiilor de proiectare:

Reconstrucție - adaptarea soluțiilor de proiectare se realizează prin prelucrarea componentelor relevante;

Parametrizare – soluțiile de proiectare sunt configurate în conformitate cu parametri specificați și modificabili;

Restructurarea modelului – se modifică modelul domeniului subiectului, ceea ce duce la reformarea automată a soluțiilor de proiectare.

În funcție de complexitatea obiectului de automatizare și de setul de sarcini care trebuie rezolvate la crearea unui AIS specific, etapele și fazele de lucru pot avea intensitate diferită a muncii. Este posibil să combinați etape succesive și să excludeți unele dintre ele în orice etapă a proiectului. De asemenea, este permisă începerea lucrărilor etapei următoare înainte de finalizarea celei anterioare.

Principalele etape ale creării unui sistem informatic automatizat:

Formarea cerințelor pentru AIS;

Dezvoltarea conceptului AIS;

Elaborarea specificațiilor tehnice;

Elaborarea unei schițe de proiect;

Dezvoltarea părții tehnice a proiectului;

Elaborarea documentației de lucru pentru AIS;

Punerea în funcțiune;

Suport AIS.

Metodologia de proiectare

Baza tehnologiei de proiectare a sistemelor informatice este metodologia. Metodologia este implementată prin tehnologii specifice și standarde, metode și instrumente suport.

Metodele de proiectare IS pot fi clasificate în funcție de gradul de utilizare a instrumentelor de automatizare, soluții standard de proiectare și adaptabilitate la schimbările așteptate. Astfel, în funcție de gradul de automatizare, metodele de proiectare sunt împărțite în:

1. Manual, în care proiectarea componentelor IS se realizează fără utilizarea unor instrumente software speciale, iar programarea se face în limbaje algoritmice;

2. Pe computer, în care soluțiile de proiectare sunt generate sau configurate (setare) pe baza utilizării unor instrumente software speciale.

Pe baza gradului de utilizare a soluțiilor standard de proiectare, se disting următoarele metode de proiectare:

1. Original (individual), atunci când soluțiile de proiectare sunt dezvoltate „de la zero” în conformitate cu cerințele pentru AIS. Se caracterizează prin faptul că toate tipurile de lucrări de proiectare sunt concentrate pe crearea de proiecte individuale pentru fiecare obiect, care să reflecte toate caracteristicile acestuia la maximum;

2. Standard, care presupune configurarea unui IS din soluții de proiectare standard gata făcute (module software). Realizat pe baza experienței acumulate în dezvoltarea proiectelor individuale. Proiectele tipice, ca o generalizare a experienței pentru anumite grupuri de sisteme organizaționale și economice sau tipuri de muncă, în fiecare caz specific sunt asociate cu multe caracteristici specifice și diferă prin gradul de acoperire a funcțiilor de management, munca efectuată și documentația de proiect elaborată.

Pe baza gradului de adaptabilitate al soluțiilor de proiectare, se disting următoarele metode:

1. Reconstrucție, când adaptarea soluțiilor de proiectare se realizează prin prelucrarea componentelor relevante (module software de reprogramare);

2. Parametrizare, atunci când soluțiile de proiectare sunt configurate (generate) în conformitate cu parametrii modificați;

3. Restructurarea modelului, când se modifică modelul zonei cu probleme, pe baza căruia soluțiile de proiectare sunt regenerate automat.

Combinația diferitelor caracteristici ale clasificării metodelor determină natura tehnologiilor de proiectare IC utilizate, dintre care se disting două clase principale: tehnologii canonice și industriale. Tehnologia designului industrial, la rândul său, este împărțită în două subclase: proiectare automată (folosind tehnologii CASE) și proiectare standard (orientată pe parametri sau pe model). Utilizarea tehnologiilor industriale nu exclude utilizarea celor canonice în unele cazuri.

Designul este activitati practice, al cărui scop este căutarea de noi soluții, prezentate sub forma unui set de documentație. Procesul de căutare este o succesiune de acțiuni și proceduri interdependente, care, la rândul lor, implică utilizarea anumitor metode. Complexitatea procesului de proiectare (ca orice altă activitate creativă), natura non-standard a situațiilor de design (viață) necesită cunoașterea diferitelor metode și capacitatea de a le stăpâni.

Tehnologia de proiectare este definită ca o combinație a trei componente:

O procedură pas cu pas care definește succesiunea operațiunilor de proiectare tehnologică;

Criterii și reguli utilizate pentru evaluarea rezultatelor operațiunilor tehnologice;

Notații (mijloace grafice și textuale) utilizate pentru a descrie sistemul proiectat.

Caracteristicile comparative ale instrumentelor de proiectare

Scopul principal al alegerii unui standard corporativ pentru designul organizațional este de a specifica un limbaj comun și obligatoriu de comunicare pentru management, dezvoltatorii de organizații și procese tehnologiceși executanții acestor procese. Aplicații speciale ale unor astfel de standarde sunt sinteza cerințelor pentru sistemele create, reglementările privind unitățile organizaționale, instrucțiunile de service etc.

Există aproximativ 30 de tehnologii pentru proiectarea sistemelor organizaționale și tehnice și câteva sute de instrumente concepute pentru a automatiza acest proces. Prin urmare, ținând cont de factorul timp, analiza comparativă s-a limitat la cele mai populare patru produse de pe piața rusă: Bpwin/Erwin (Platinum Technology), Rational Rose (Rational Software Corporation), ARIS (Scheer AG) și Oracle Designer ( Oracle Developer Suite). Datele de referință privind tehnologiile CASE și instrumentele de proiectare sunt prezentate mai jos în text și în Tabelul nr. 1.

Tabelul 1

Instrumente de proiectare și caracteristicile lor comparative

Criterii				Oracle Designer
Suport complet pentru ciclul de viață IP
Asigurarea integrității proiectului
Independent de platformă	+ (DoDAF, TeaF/FeaT, Zachman)	+ (ORACLE, Informix, Sybase)	+ (ORACLE, Informix, Sybase, Ingres etc.)
Dezvoltare simultană în grup de baze de date și aplicații

*) Dezvoltatorii de aplicații pot începe să lucreze cu baza de date numai după ce proiectarea acesteia a fost finalizată.

Tehnologia CASE este o metodologie de proiectare IS, precum și un set de instrumente care vă permit să modelați vizual un domeniu, să analizați acest model în toate etapele dezvoltării și întreținerii SI și să dezvoltați aplicații în conformitate cu nevoile de informații ale utilizatorilor. Majoritatea instrumentelor CASE existente se bazează pe metodologii de analiză și proiectare structurale (în mare parte) sau orientate pe obiecte, folosind specificații sub formă de diagrame sau texte pentru a descrie cerințele externe, relațiile dintre modelele de sistem, dinamica comportamentului sistemului și arhitectura software.

Potrivit unei analize a tehnologiilor avansate compilată de Systems Development Inc. în 2007, pe baza rezultatelor unui sondaj a peste 1.000 de companii americane, tehnologia CASE este în prezent clasată printre cele mai stabile tehnologii informaționale (jumătate dintre utilizatorii chestionați au folosit-o în mai mult de o treime din proiectele lor, dintre care 85% au fost finalizat cu succes). Cu toate acestea, în ciuda tuturor capabilităților potențiale ale instrumentelor CASE, există multe exemple de implementare nereușită a acestora, ca urmare a cărora instrumentele CASE devin „raft”. În acest sens, trebuie reținut următoarele:

1. Instrumentele CASE nu au neapărat un efect imediat; poate fi primit doar după ceva timp;

2. Costurile reale de implementare a instrumentelor CASE depășesc de obicei cu mult costurile de achiziție a acestora;

3. Instrumentele CASE oferă oportunități de a obține beneficii semnificative numai după finalizarea cu succes a procesului de implementare a acestora.

Datorită naturii variate a instrumentelor CASE, ar fi eronat să se facă declarații generale cu privire la satisfacția reală a oricărei așteptări date de la implementarea lor. Pot fi enumerați următorii factori care fac dificilă determinarea efectului posibil al utilizării instrumentelor CASE:

1. O mare varietate de calitate și capabilități ale instrumentelor CASE;

2. Timp relativ scurt de utilizare a instrumentelor CASE în diverse organizații și lipsă de experiență în utilizarea acestora;

3. Varietate mare în practicile de implementare ale diferitelor organizații;

4. Lipsa unor metrici și date detaliate pentru proiectele deja finalizate și în derulare;

5. Gamă largă de domenii ale proiectelor;

6. Grade variate de integrare a instrumentelor CASE în diferite proiecte.

Ca urmare a acestor complexități, informațiile disponibile despre implementările reale sunt extrem de limitate și inconsecvente. Depinde de tipul de instrumente, de caracteristicile proiectului, de nivelul de suport și de experiența utilizatorului. Unii analiști consideră că beneficiile reale ale utilizării unor tipuri de instrumente CASE pot fi realizate doar după unul sau doi ani de experiență. Alții cred că impactul poate avea loc de fapt în timpul fazei operaționale a ciclului de viață IS, când îmbunătățirile tehnologice pot duce la scăderea costurilor de operare.

Categoria SP include atât sisteme relativ ieftine pentru computere personale (PC-uri) cu capacități foarte limitate, cât și sisteme scumpe pentru platforme de calcul și medii de operare eterogene. Astfel, piața modernă de software include aproximativ 30 de sisteme CASE diferite, dintre care cele mai puternice, într-un fel sau altul, sunt folosite de aproape toate companiile occidentale de top.

Utilizarea SP necesită pregătire și instruire specială din partea potențialilor utilizatori. Experiența arată că implementarea SP este lentă, totuși, pe măsură ce se dobândesc abilități practice și o cultură generală de design, eficiența utilizării acestor instrumente crește brusc, iar cea mai mare nevoie de utilizare a SP este experimentată în etapele inițiale de dezvoltare, și anume la etapele analizei si specificarii cerintelor. Acest lucru se explică prin faptul că costul erorilor făcute în etapele inițiale este cu câteva ordine de mărime mai mare decât costul erorilor identificate în etapele ulterioare de dezvoltare.

Astăzi, piața rusă de software are următoarele asociații comune cele mai dezvoltate:

ERWin/BPWin;

Trandafir rațional;

Oracle Designer.

ARIS - Un instrument integrat de modelare a proceselor de afaceri care combină o varietate de metode de modelare și analiză a sistemelor. În primul rând, este un mijloc de descriere, analiză, optimizare și documentare a proceselor de afaceri decât un instrument de proiectare software.

BPWin este un instrument pentru modelarea vizuală a proceselor de afaceri. ERWin este un instrument folosit pentru modelarea și crearea bazelor de date de complexitate arbitrară bazate pe diagrame entitate-relație.

Rational Rose este un instrument pentru modelarea sistemelor informaționale orientate pe obiecte. Vă permite să rezolvați aproape orice problemă în proiectarea sistemelor informaționale: de la analiza proceselor de afaceri până la generarea de cod într-un limbaj de programare specific. Vă permite să dezvoltați atât modele la nivel înalt, cât și la nivel scăzut, realizând astfel fie design abstract, fie logic.

Oracle Designer este un instrument funcțional pentru descrierea unui domeniu. Inclus în setul de instrumente Oracle9i Developer Suite pentru proiectarea sistemelor software și a bazelor de date care implementează tehnologia CASE și metodologia de dezvoltare IS proprie a Oracle - „CDM”, permițând echipei de dezvoltare să realizeze un proiect, pornind de la analiza procesului de afaceri prin modelare până la generarea de cod. și obținerea prototipului și ulterior a produsului final. Acest instrument are sens atunci când vizează întreaga linie de produse Oracle care este utilizată pentru a proiecta, dezvolta și implementa un sistem software complex.

Analiza datelor prezentate în tabel arată că, din societățile mixte listate, doar complexul ARIS îndeplinește cel mai pe deplin toate criteriile acceptate ca principale. De exemplu, în complexul Rational Rose, integritatea bazei de date de proiectare și o tehnologie de proiectare IC unificată end-to-end este asigurată prin utilizarea interfeței Corba. Trebuie remarcat faptul că fiecare dintre cele două produse este în sine unul dintre cele mai puternice din clasa sa.

Astfel, cel mai dezvoltat mijloc de dezvoltare a SI pe scară largă astăzi, potrivit autorului, este complexul ARIS.

Introducere

Concluzie

Literatură

Introducere

Dezvoltare diverse domenii activitatea umană în stadiul actual este imposibilă fără utilizarea pe scară largă a tehnologiei informatice și crearea de sisteme informaționale în diverse direcții. Procesarea informațiilor în astfel de sisteme a devenit un domeniu științific și tehnic independent.

După etapa de construire a unui model de informații, începe proiectarea sistemului. În această etapă se realizează o selecție de soluții tehnologice pe baza cărora va fi construit sistemul informațional.

Informații în lumea modernă a devenit una dintre cele mai importante resurse, iar sistemele informaționale (SI) au devenit instrument necesarîn aproape toate domeniile de activitate.

În condiții reale, proiectarea este o căutare a unei metode care să satisfacă cerințele funcționalității sistemului folosind tehnologiile disponibile, ținând cont de restricțiile date.

Varietatea problemelor rezolvate cu ajutorul sistemelor informaționale a dus la apariția multor tipuri diferite de sisteme, care diferă prin principiile de construcție și regulile de prelucrare a informațiilor încorporate în acestea.

Scopul testului este de a analiza pas cu pas procesul de creare a sistemelor informatice.

Obiectivele acestei lucrări sunt de a afla scopul principal al proiectării, precum și scopul creării sistemelor informaționale.

1. Proiectarea sistemelor informatice

Proiectarea sistemelor informatice începe întotdeauna cu definirea scopului proiectului. Sarcina principală a oricărui proiect de succes este să se asigure că în momentul lansării sistemului și pe tot parcursul funcționării acestuia este posibil să se asigure:

· funcționalitatea necesară a sistemului și gradul de adaptare la condițiile în schimbare ale funcționării acestuia;

· capacitatea necesară a sistemului;

· timpul necesar de răspuns al sistemului la o solicitare;

· funcționarea fără probleme a sistemului în modul cerut, cu alte cuvinte, disponibilitatea și disponibilitatea sistemului de a procesa cererile utilizatorilor;

· ușurință în operare și suport al sistemului;

· securitatea necesară.

Performanța este principalul factor care determină eficacitatea unui sistem. Designul bun este baza unui sistem de înaltă performanță.

Proiectarea sistemelor informatice acoperă trei domenii principale:

· proiectarea obiectelor de date care vor fi implementate în baza de date;

· proiectarea de programe, formulare de ecran, rapoarte care să asigure executarea interogărilor de date;

· luarea în considerare a mediului sau tehnologiei specifice, și anume: topologia rețelei, configurația hardware, arhitectura utilizată (fișier-server sau client-server), procesare paralelă, prelucrare distribuită a datelor etc.

Conform metodologiei moderne, procesul de creare a unui SI este un proces de construire și transformare secvențială a unui număr de modele coordonate în toate etapele ciclului de viață al SI (LC). La fiecare etapă a ciclului de viață se creează modele specifice acestuia - organizație, cerințe IS, proiect IS, cerințe aplicație etc. Modelele sunt formate din grupuri de lucru ale echipei de proiect, salvate și acumulate în depozitul de proiect. Crearea modelelor, controlul, transformarea și furnizarea acestora pentru uz colectiv se realizează cu ajutorul instrumentelor software speciale - instrumente CASE.

Procesul de creare a unui IP este împărțit într-un număr de etape (etape), limitate de un anumit interval de timp și care se termină cu lansarea unui anumit produs (modele, produse software, documentație etc.).

De obicei, se disting următoarele etape ale creării unui IS: formarea cerințelor de sistem, proiectare, implementare, testare, punere în funcțiune, operare și întreținere.

Etapa inițială a procesului de creare a SI este modelarea proceselor de afaceri care au loc într-o organizație și realizarea scopurilor și obiectivelor acesteia. Modelul de organizare, descris în termeni de procese de afaceri și funcții de afaceri, ne permite să formulăm cerințele de bază pentru SI. Această poziție fundamentală a metodologiei asigură obiectivitatea în dezvoltarea cerințelor de proiectare a sistemului. Setul de modele pentru descrierea cerințelor SI este apoi transformat într-un sistem de modele care descriu designul conceptual al SI. Modele de arhitectură IS, cerințe software și suport informativ(IO). Apoi se formează arhitectura software și informațională, se identifică bazele de date corporative și aplicațiile individuale, se formează modele de cerințe ale aplicațiilor și se realizează dezvoltarea, testarea și integrarea acestora.

Scopul etapelor inițiale ale creării unui SI, realizate în etapa de analiză a activităților organizației, este de a formula cerințe pentru SI care să reflecte corect și cu acuratețe scopurile și obiectivele organizației client. Pentru a preciza procesul de creare a unui sistem informațional care să răspundă nevoilor organizației, este necesar să se afle și să se articuleze clar care sunt aceste nevoi. Pentru a face acest lucru, este necesar să se determine cerințele clienților pentru SI și să le mapeze într-un limbaj model în cerințele pentru dezvoltarea unui proiect IS, astfel încât să se asigure conformitatea cu scopurile și obiectivele organizației.

Sarcina de formare a cerințelor pentru sistemele informaționale este una dintre cele mai importante, dificil de formalizat și cea mai costisitoare și dificil de corectat în cazul unei erori. Instrumentele și produsele software moderne vă permit să creați rapid IP în conformitate cu cerințele gata făcute. Dar adesea aceste sisteme nu mulțumesc clienții și necesită numeroase modificări, ceea ce duce la o creștere bruscă a costului real al IP. Motivul principal pentru această situație este definirea incorectă, inexactă sau incompletă a cerințelor SI în etapa de analiză.

În etapa de proiectare, modelele de date sunt mai întâi formate. Designerii primesc rezultatele analizei ca informații inițiale. Construirea modelelor de date logice și fizice este o parte fundamentală a proiectării bazei de date. Modelul informațional obținut în timpul procesului de analiză este mai întâi convertit într-un model de date logic și apoi într-un model de date fizic.

În paralel cu proiectarea schemei bazei de date, se realizează proiectarea procesului pentru a obține specificațiile (descrierile) tuturor modulelor IS. Ambele procese de proiectare sunt strâns legate deoarece o parte din logica de afaceri este de obicei implementată în baza de date (constrângeri, declanșatoare, proceduri stocate). Scopul principal al proiectării proceselor este de a mapa funcțiile obținute în timpul fazei de analiză în module ale sistemului informațional. La proiectarea modulelor, se determină interfețele programului: aspectul meniului, aspectul ferestrei, tastele rapide și apelurile aferente.

Produsele finale ale fazei de proiectare sunt:

· diagrama bazei de date (pe baza modelului ER dezvoltat în etapa de analiză);

· un set de specificații ale modulelor de sistem (sunt construite pe baza modelelor funcționale).

În plus, în faza de proiectare, se realizează și dezvoltarea arhitecturii IS, inclusiv selecția platformei (platformelor) și a sistemului de operare (sisteme de operare). Într-un IS eterogen, mai multe computere pot rula pe platforme hardware diferite și pot rula sisteme de operare diferite. Pe lângă alegerea unei platforme, în etapa de proiectare sunt determinate următoarele caracteristici de arhitectură:

· dacă va fi o arhitectură „fișier-server” sau „client-server”;

· va fi o arhitectură pe 3 niveluri cu următoarele straturi: server, middleware (server de aplicații), software client;

· dacă baza de date va fi centralizată sau distribuită. Dacă baza de date este distribuită, atunci ce mecanisme vor fi utilizate pentru a menține consistența și relevanța datelor;

· dacă baza de date va fi omogenă, adică dacă toate serverele de baze de date vor fi produse ale aceluiași producător (de exemplu, toate serverele sunt numai Oracle sau toate serverele sunt numai DB2 UDB). Dacă baza de date nu este omogenă, atunci ce software va fi folosit pentru schimbul de date între SGBD-uri de la diferiți producători (deja existente sau special dezvoltate în cadrul proiectului);

· dacă serverele de baze de date paralele (de exemplu, Oracle Parallel Server, DB2 UDB) vor fi utilizate pentru a obține o performanță adecvată.

Etapa de proiectare se încheie cu elaborarea unui proiect tehnic al IP. În etapa de implementare este creat un software pentru documentația operațională.

După finalizarea dezvoltării unui modul individual de sistem, se efectuează un test de sine stătător, care are două obiective principale:

· detectarea defecțiunilor modulelor (defecțiuni grave);

· conformitatea modulului cu specificația (prezența tuturor funcțiilor necesare, absența funcțiilor inutile).

După ce testul autonom trece cu succes, modulul este inclus în partea dezvoltată a sistemului, iar grupul de module generate trece testele de conectare care ar trebui să urmărească influența lor reciprocă.

Apoi, un grup de module este testat pentru fiabilitatea operațională, adică trec, în primul rând, teste care simulează defecțiuni ale sistemului și, în al doilea rând, teste între defecțiuni. Primul grup de teste arată cât de bine se recuperează sistemul de la defecțiuni software și hardware. Al doilea grup de teste determină gradul de stabilitate a sistemului în timpul funcționării normale și vă permite să estimați timpul de funcționare al sistemului. Suita de teste de robustețe ar trebui să includă teste care simulează sarcina maximă a sistemului.

Apoi, întregul set de module este supus unui test de sistem - un test intern de acceptare a produsului, care arată nivelul calității acestuia. Acestea includ teste de funcționalitate și teste de fiabilitate a sistemului.

Ultimul test al sistemului informatic este testarea de acceptare. Un astfel de test presupune arătarea sistemului informațional către client și trebuie să conțină un grup de teste care simulează procese reale de afaceri pentru a arăta conformitatea implementării cu cerințele clientului.